Skip to content

[ES|QL] RERANK command validation support #221004

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

vadimkibana
Copy link
Contributor

Summary

Partially addresses #217285

Checklist

@vadimkibana
Copy link
Contributor Author

/ci

@vadimkibana vadimkibana marked this pull request as ready for review May 22, 2025 11:58
@vadimkibana vadimkibana requested a review from a team as a code owner May 22, 2025 11:58
@vadimkibana vadimkibana added review release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting Feature:ES|QL ES|QL related features in Kibana Team:ESQL ES|QL related features in Kibana v9.1.0 labels May 22, 2025
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-esql (Team:ESQL)

@streamich streamich requested a review from a team as a code owner May 22, 2025 13:31
@streamich streamich requested a review from a team as a code owner May 22, 2025 16:46
@botelastic botelastic bot added the ci:project-deploy-observability Create an Observability project label May 22, 2025
Copy link
Contributor

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

  • /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
  • run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

@stratoula
Copy link
Contributor

@drewdaemon can you take this PR review?

@elasticmachine
Copy link
Contributor

elasticmachine commented May 23, 2025

💛 Build succeeded, but was flaky

  • Buildkite Build
  • Commit: 989cbf7
  • Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-221004-989cbf772d54

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #54 / Cloud Security Posture Old Data Findings page with old data returns data grid with only data within retention CSPM
  • [job] [logs] AppEx AI-Infra Inference APIs FTR tests / Inference plugin - API integration tests Connector bedrock-claude-3-5-sonnet chatComplete API streaming enabled executes a tool when explicitly requested
  • [job] [logs] FTR Configs #69 / Synthetics API Tests SyncGlobalParams parsed params for previously added http monitors

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
esql 202 203 +1
lists 430 431 +1
securitySolution 7399 7400 +1
stackAlerts 256 257 +1
unifiedSearch 364 365 +1
total +5

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/esql-ast 263 264 +1
@kbn/esql-validation-autocomplete 163 168 +5
total +6

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
kbnUiSharedDeps-srcJs 3.7MB 3.7MB +2.9KB
Unknown metric groups

API count

id before after diff
@kbn/esql-ast 329 330 +1
@kbn/esql-validation-autocomplete 184 191 +7
total +8

References to deprecated APIs

id before after diff
@kbn/esql-validation-autocomplete 3 2 -1

History

Comment on lines +92 to +105
export const isContainedLocation = (container: ESQLLocation, contained: ESQLLocation): boolean => {
return container.min <= contained.min && container.max >= contained.max;
};

export const isContained = (
container: { location?: ESQLLocation },
contained: { location?: ESQLLocation }
): boolean => {
if (!container.location || !contained.location) {
return false;
}

return isContainedLocation(container.location, contained.location);
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be redundant with within

Can we dedupe?

Comment on lines +370 to +375
const isParentShowCommand =
!args.length &&
(ctx.parent?.node as any)?.type === 'command' &&
(ctx.parent?.node as any)?.name === 'show';

const formatted = isParentShowCommand ? operator : `${operator}(${args})`;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is fixing an unrelated bug right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain the thinking behind this new pattern? (command definition living in its own module?)

Comment on lines +418 to +436
/**
* Return nicely formatted human-readable out of parser errors. This callback
* lets commands construct their own error messages out of parser errors,
* as parser errors have the following drawbacks:
*
* 1. Not human-readable, even hard to read for developers.
* 2. Not translated to other languages, e.g. Chinese.
* 3. Depend on ANTLR grammar, which is not stable and may change in the future.
*
* @param parsingErrors List of parsing errors returned by the ANTLR parser
* for this command.
* @returns Human-readable, translatable messages for the user.
*/
parsingErrorsToMessages?: (
parsingErrors: EditorError[],
command: ESQLCommand<CommandName>,
references: ReferenceMaps
) => ESQLMessage[];

Copy link
Contributor

@drewdaemon drewdaemon May 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Till now we have relied on a clean passthrough of ANTLR errors despite their limitations. This new idea raises the following questions for me

  • When is this expected?
    • Do we need to add these for every new command?
    • Which messages are important enough to give this special treatment to? Surely not all messages?
  • We don't control the parser messages. How often will they change in our grammar update PRs, requiring us to update this logic?
  • Is it ok to introduce this on an ad-hoc basis (as we have here) or should we do it holistically for all commands (if we're going to do it)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting ci:project-deploy-observability Create an Observability project Feature:ES|QL ES|QL related features in Kibana release_note:skip Skip the PR/issue when compiling release notes review Team:ESQL ES|QL related features in Kibana v9.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants